1. Field of the Invention
The present invention relates generally to an improved data processing system and, in particular, to a computer implemented method, an apparatus, and a computer usable program product for optimizing performance in a data processing system. Still more particularly, the present invention provides a method, system, and computer program product for enhancing performance by controlling startup request flooding by incrementally growing a Web container.
2. Description of the Related Art
Enterprise Java Beans (EJB) technology is the server-side component architecture for the Java™ 2 Platform, Enterprise Edition (J2EE) platform (Java is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both). EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java™ technology.
A cluster is a group of application servers that transparently runs a J2EE application as if it were a single entity. A J2EE instance is a unit in the J2EE cluster, which can be started, stopped, and monitored separately. It runs on a physical server, but it is also possible to run several instances on one server. An instance is identified by a System ID (SID) and an instance number. Central Services are a special example of the J2EE instance. Another special instance is the one that installed the Software Deployment Manager (SDM). This one usually runs with the database and Central Services on the same machine and is then indicated as the central instance.
The J2EE instance contains at least one Server Process. Normally the J2EE instance comprises one J2EE Dispatcher and several server processes. The J2EE instance is started and stopped by the J2EE Startup and Control Framework. For example, the J2EE dispatcher receives the request, selects a server process for the processing and establishes the connection from a client to the server.
J2EE Web sites frequently experience failures shortly after the application server starts up or is restarted after a failure. Often, Web sites activate new application server instances to provide additional capacity during intense periods of activity. Also, many J2EE application servers automatically restart failed instances to automatically maintain site capacity.
However, a freshly started J2EE application server instance usually does not have the same capacity as a longer-lived application server instance operating at steady-state. The difference is in the startup required for the newly started instance to fully optimize key functions, such as the Just-In-Time compiler in the Java™ Virtual Machine, to build critical object pools such as the database connection pools, and to populate caches. Until this occurs, the application server instance requires more of a CPU's time and memory to handle requests.
Most Web sites tune the J2EE application server instance to operate efficiently at steady-state. The plan is to start the application server instances during a time of relative low activity and allow them to startup during off-peak hours. Application server instances start up gradually only because of the transition from off-peak hours to peak hours, not because the startup is controlled or regulated. When the site comes under peak loading, the application server instance will already be at steady state. The application server instance is not tuned to take a flood of requests during startup, as this would require more capacity than the steady-state model, and thus cost more in hardware and software licenses. Most customers do not want to purchase extra capacity they will need infrequently or for very brief periods of time.
However, if the application server instance is flooded with requests during startup, it often fails because it runs out of memory or enters CPU thrashing rather than doing useful work. Of course, simply restarting the application server instance failing under these circumstances simply puts the application server instance in a cycle of failure until the overall site load diminishes sufficiently for the application server instance to come up successfully and achieve steady-state.
During these periods of failure during startup or restart, the user requests routed to the newly started application server instance experience extreme response times or failure. These issues are exposed to the site users, and impact customer satisfaction and the site's perceived reliability.
Most existing solutions to the problem require flow control front-end hardware such as load balancers. However, this equipment focuses on spraying to specific IP addresses and ports. Any plug-in software spraying (frequently provided by the J2EE application server) often defeats the usefulness of the hardware throttling as it hides the application server instances from the hardware balancer. The hardware load balancer may avoid sending requests to the application server instance that is starting up, but the plug-in software sprayer may defeat the purpose of the balancer by redirecting requests to the under-utilized application server instance. Even if the customer chooses to force a topology that supports hardware throttling, coordination of the throttling mechanism and timing requires coordination between the network team and the J2EE Web site team. Often this is difficult to achieve due to the customer's organization structure. In these cases, the J2EE Web site team would like a reliable mechanism they could configure without outside help to control request flow to newly started application server instances.